home *** CD-ROM | disk | FTP | other *** search
/ PsL Monthly 1993 October / PSL Monthly Shareware CD-ROM (Public Software Library) (October 1993).iso / dos / prgmming / progrmmr.let < prev    next >
Encoding:
Text File  |  1993-08-30  |  9.9 KB  |  230 lines
  1.                           PsL Programmers Newsletter
  2.  
  3.                           Copyright October 1993 PsL
  4.  
  5.  
  6. Contents:
  7. ========
  8. 1. MEI Is Now Marketing Low-Cost Shareware CDs
  9. 2. "Extras" You Should Be Adding to Your Files
  10.     - CD-ROM Acceptable File Names
  11.     - Screen Shots
  12.     - File Viewer
  13.     - Make Your Installation Generic
  14.     - Don't Leave Out Windows' Files
  15.     - Tell us your preferred ZIP file name
  16.       = Commentary: Anti-Version-Number-In-ZIP-Name
  17. 3. Why Did You Write that Program?
  18.  
  19.  
  20. Text:
  21. ====
  22.  
  23. 1. MEI Is Now Marketing Low-Cost Shareware CDs:
  24.  
  25. MEI, the company that sends out about a jillion catalogs a month selling
  26. low-cost disks and other computer supplies featured shareware CDs on the cover
  27. of their latest catalog.
  28.  
  29. On the inside, front cover was a remarkably good shareware explanation.
  30.  
  31. As Rob Rosenberg put in on the ASPFORUM on CompuServe: "This may be a sign
  32. that the CD-ROM revolution is finally on its way."
  33.  
  34. PsL is beginning a national advertising campaign which will let people get a
  35. CD-ROM drive and three months of the PsL Monthly CD for a total (including the
  36. drive) of as little as $66 per month. At that price, who can afford NOT to
  37. have a CD-ROM drive?
  38.  
  39.  
  40. 2. "Extras" You Should Be Adding to Your Files:
  41.  
  42. Do you want to reach the broadest possible market with the greatest impact?
  43.  
  44. If so, there are some easy, no-cost steps you can take to increase the chances
  45. that your program will be distributed by as many sources as possible.
  46.  
  47. - CD-ROM Acceptable File Names:
  48.  
  49. CD-ROMs only allow file names with letters, numbers, and the underscore sign
  50. ("_") in them - no dashes or other non-alphanumeric characters.
  51.  
  52. - Screen Shots:
  53.  
  54. A reader (of a shareware catalog) can tell more about a program from a single
  55. screen shot than from a two-paragraph write-up. It is always time-consuming,
  56. often difficult, and sometimes impossible to get screen shots.
  57.  
  58. If you have a text-based application, such as a database program, bring up a
  59. good screen with data on it, capture it, and save it as a PCX file, preferably
  60. in color.
  61.  
  62. I use Paint Shop Pro in Windows to do screen captures. It's the easiest way to
  63. capture a DOS-based text screen in graphic format.
  64.  
  65. - File Viewer:
  66.  
  67. Put VIEW.COM from the PsL CD-ROM on your disks. This is a freeware file viewer
  68. by David Dibble. It takes less than 1k of disk space.
  69.  
  70. Then make a batch file to display all your DOCs, READ.MEs, etc., in the order
  71. you prefer.
  72.  
  73. - Make Your Installation Generic:
  74.  
  75. Don't assume that people will be installing your program from a floppy drive
  76. A: or B:. If someone has downloaded your program in ZIP format or gotten it
  77. off a CD-ROM, they will un-ZIP the files to their hard disk.
  78.  
  79. Ideally, no further "installation" should be required once the files are in a
  80. directory on the hard disk. However, some programmers combine the copying of
  81. files to the hard disk with the system set up (moving data files to specific
  82. subdirectories and selecting screen colors and other system configuration
  83. options).
  84.  
  85. So in order to select screen colors, the user has to run the INSTALL and let
  86. it copy the files to a *different* directory. At worst, the user may have to
  87. copy the files to a floppy just so the INSTALL can copy them back to the hard
  88. disk!
  89.  
  90. The configuration functions should be done from a configuration program or
  91. from a menu option in the main program, and the install program should just do
  92. the copying to the hard disk.
  93.  
  94. Here's something even worse than the "at worst", above: at PsL, we get some
  95. multi-disk programs which can only be installed from individual floppies. So
  96. not only must the user copy the files to *a* floppy, he must copy them to
  97. multiple 360k floppies. Then he/she may have to use DOS's LABEL command to
  98. give the floppies specific labels which the installation is looking for.
  99.  
  100. Talk about discouraging users...
  101.  
  102. - Don't Leave Out Windows' Files:
  103.  
  104. We tested the installation of a Windows app and it worked fine. The first user
  105. to try it couldn't get it to install. Turned out that the installation
  106. required a bunch of files which we (and the programmer, obviously) already
  107. had, but which the user did not. (Actually, they were on the disk, but in
  108. compressed format, which Windows could not use.)
  109.  
  110. We spent an hour on the phone with the customer trying to work around it, but
  111. ended up sending him disks with the program already installed on them. The
  112. customer called back again - CMDIALOG.VBX was missing. That was one file we
  113. could not tell from the PACKING.LST was required, so we were out another disk
  114. and postage.
  115.  
  116. Moral: test your Windows apps on a virgin machine before distributing them to
  117. make sure you are including all the files that are needed. Alternatively, if
  118. you have a large hard drive or a Bernoulli drive, install a virgin copy of
  119. Windows on it, then for testing, change your PATH to that copy and run under
  120. it.
  121.  
  122. One exception to this is VBRUN?00.DLL. If you bloat up your archive by
  123. including the huge VB runtime modules, you greatly reduce the number of people
  124. willing to download the program from BBSs. Most people already have the
  125. runtimes and for those who don't, most vendors and BBSs make them available
  126. separately.
  127.  
  128. This raises the issue of VB programmers using SETUP.EXE to install their
  129. programs. This may look nice, but it is really a pain in the anatomy.
  130.  
  131. In the first place, it forces you to include the VBRUN module. For another, it
  132. forces some to go through an installation just to look at the program. The
  133. only benefit seems to be that it lets you automatically create a program group
  134. in PM for your app, which most users already know how to do (if they are using
  135. shareware).
  136.  
  137. Using SETUP.EXE is not a bad idea for your registered versions, but for the
  138. shareware versions, stick with just archiving the files.
  139.  
  140.  
  141. - Tell us your preferred ZIP file name:
  142.  
  143. Some programmers send us their software on disk(s) unarchived, but upload to
  144. BBSs in ZIP format. CD-ROM publishers have to make up an archive name which
  145. may not match the one you used, which tends to make sysops unhappy.
  146.  
  147. Anti-Version-Number-In-ZIP-Name Pitch:
  148.  
  149. Are version numbers in archive names really necessary or desirable?
  150.  
  151. With FILES.BBS files and FILE_ID.DIZ files to tell callers the version number,
  152. isn't it redundant to put the version number in the file name?
  153.  
  154. If you do NOT put the version number in the archive name (and assuming you
  155. use the same archive name each time), then you can be assured that old copies
  156. of your program will be replaced by the new one; otherwise, there are sure to
  157. be multiple (outdated) versions of your program(s) floating around.
  158.  
  159. Take a look at one of these CDs with "20,000 different programs" on them.
  160. About 10,000 of them are the same programs with different archive names.
  161.  
  162. A sysop called PsL this month to say that he already had "99%" of the software
  163. on our CD - or at least that is what his system told him when he tried to
  164. upload software from our CD to his multi-gig hard disk.
  165.  
  166. What was really happening was that the programs without version numbers in the
  167. names were trying to write over old versions with the same names. In other
  168. words, the sysop was being forced to replace old versions with new ones or to
  169. not add the new program at all. The reverse implication is that all the
  170. programs with version numbers in the names made it on ok, LEAVING THE OLD
  171. VERSIONS intact on his system.
  172.  
  173. I've been told that using the same ZIP file name each time causes a problem
  174. for sysops because the author cannot upload a new file with the same name.
  175. Isn't there some way around this? Couldn't their be a "new uploads" section
  176. where a new file with the same name would not overwrite an old one.
  177.  
  178.  
  179. 3. Why Did You Write that Program?
  180.  
  181. Look at the Quick Looks in this month's PsL News and you'll see program after
  182. program of stuff that has already been done to death - and often done better.
  183.  
  184. I suspect the reason for this is because the programmers simply are unaware
  185. that similar programs already existed. There's an easy solution to that
  186. problem - check out PsL's Reviews Files. If you don't see your idea for a
  187. program written up in our reviews, the odds are pretty good that nobody has
  188. written one like it yet.
  189.  
  190. When I asked a programmer once why he had written a utility when there were
  191. dozens just like it, he took offense and said he did it for the fun of it and
  192. if he wanted to put it out as shareware, that was his business.
  193.  
  194. That's true -- as long as you don't expect to make any money from it. (But
  195. then, why make it shareware?)
  196.  
  197. "Mine's Better":
  198.  
  199. If you write a program that has been done many times before because you think
  200. yours is better, be sure to explain HOW yours is better in the docs (unless
  201. you don't really care about getting registrations either).
  202.  
  203. Saying that yours is faster or easier doesn't cut much mustard unless you can
  204. clearly substantiate those claims. For example, the author of a utility this
  205. month for renaming directories says his is "faster". Well, on my system
  206. renaming a subdirectory with an old freeware utility is darn near
  207. instantaneous. There's not a snowball's chance I'm going to pay $10 for a new
  208. utility just because it claims to be faster.
  209.  
  210. A letter to the editor of PC Magazine makes a good point, even though the
  211. writer is talking about video cards:
  212.  
  213. "For me, a difference of a fraction of [a second] is less important than the
  214. assurance that I'm not going to waste hours wading through bad documentation.
  215. When the performance difference is slight, the real issue becomes reliability
  216. and features."
  217.  
  218.  
  219. Are You Up Against Freeware?:
  220.  
  221. A lot of authors can see the handwriting on the wall (and know that the
  222. handwriting is never going to be on a check) and make their trivial utilities
  223. freeware.
  224.  
  225. Yes, you can ask whatever you please for your program, but if you see programs
  226. in our Reviews files which do the same thing and they are free, don't expect
  227. too many registrations.
  228.  
  229.  
  230.